home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Netware Super Library
/
Netware Super Library.iso
/
note_tip
/
tsrbug
/
tsrbug.txt
Wrap
Text File
|
1990-05-24
|
5KB
|
114 lines
I have run into what appears to be a bug in NetWare 2.15. This
has been reported to me by others, but I personally experienced
it on a PS/2 Model 70 running DOS 3.3. Can you confirm this as
a bug, and can you suggest a workaround?
Here is the simplest way I found to exhibit the problem: On a
Novell client station, you first run the program listed below.
What the program does is this: It intercepts the INT 21 vector
and then it TSRs. Thereafter all INT 21s pass through this program.
The INT 21 interception is extremely benign, and should not adversely
affect normal DOS operation. It calls the standard INT 21 service,
and then checks whether the function just completed was DOS function 3D
(to open an existing file). If it was not 3D, then control is returned
to the caller. If the call was a 3D, then, prior to returning to the
caller, we do a DOS function 19 (which merely returns the current
default disk drive), and then return to the caller. The registers
are properly preserved across the function 19, so there should be no
adverse effect from this extra DOS call.
The above-described program runs without incident under a normal
DOS environment. However, when you run it on the Novell client
(running it after all NetWare is installed, of course), and then
use the DOS "TYPE" command to type a file which is located on a
drive on a remote server, the resulting display will show a perpetual
stream of junk. Note that this problem DOESN'T happen when you type
a file from a local disk, only when you type a remote file.
I examined this with my debugger to determine as precisely as I
could what was happening. The TYPE command opens the file to be
typed with a DOS function 3D. The TSR intercepts that and follows
it with a function 19. Then the TYPE command continues by attempting
to read the data from the file with a DOS function 3F. It is the
function 3F that actually screws up: It returns an incorrect byte
count (in my case it returned a byte count of 6, even though the file
size was something like 200), and it doesn't properly fill the buffer.
The TYPE command repeats the function 3F as it attempts to read the
entire file, but EOF is never reached. Every subsequent call to 3F
returns the same byte count and the same buffer. So TYPE continues
to fill the screen with the same junk, ad infinitum.
Unfortunately, the problem is not so simple as a DOS function 3F
failing following a 3D and a 19. That sequence seems to work OK in
a simple test program. Something specific about the TYPE situation
causes this problem to manifest.
You can see the program below, and confirm that there is nothing
about this simple program that should interfere with the integrity
of the operating system.
-- David Rolfe
Below is the source of TEST.ASM. To generate a .COM file:
MASM test;
LINK test;
EXE2BIN test.exe test.com
cseg SEGMENT
ASSUME cs:cseg,ds:cseg
ORG 100h
Start: mov ax,3521h ;Read current INT 21 vector
int 21h
mov WORD PTR OldINT21[0],bx ;Store for later
mov WORD PTR OldINT21[2],es ; ..
mov ax,2521h ;Steal INT 21 vector
mov dx,OFFSET MyINT21
int 21h
mov ax,3100h ;Terminate and stay resident
mov dx,OFFSET Last+15
shr dx,1
shr dx,1
shr dx,1
shr dx,1
int 21h
ASSUME cs:CSEG,ds:nothing,es:nothing,ss:nothing
OldINT21 DD ? ;Original INT 21 vector stored here
DOSfnc DB ? ;Local temp storage of INT 21 function
MyINT21 PROC FAR
mov DOSfnc,ah ;Store requested INT 21 function
pushf ;Call standard INT 21 service
call OldINT21
jc MyInt2 ;If INT 21 failed, we do nothing
pushf ;Preserve flags returned by INT 21
cmp DOSfnc,3Dh ;If wasn't INT 21 function 3Dh, do nothing
jne MyInt1 ; ..
push ax ;Preserve ax returned by funcion 3Dh
mov ah,19h ;Do DOS function 19h
cli
pushf
call OldINT21
pop ax ;Restore ax destroyed by function 19h
MyInt1: popf ;Restore flags
MyInt2: ret 2 ;Return to caller
MyINT21 ENDP
Last LABEL BYTE
cseg ENDS
END Start